1. Field of the Invention
The present invention generally relates to the use of virtual tape libraries (VTLs) for use in disaster recovery (DR) of enterprise production data and, more specifically, to manners of migrating production data from a local VTL to one or more logical partitions of a remote, second-tier disk storage system such as a virtual library extension made up of virtual multi-volume cartridges (VMVCs) holding a plurality of virtual tape volumes (VTVs).
2. Relevant Background
Businesses and other organizations rely on data processing systems to manage a wide range of internal and external functions, including accounting and inventory functions, data management functions, and many others. Many of these systems must be available to be accessed over local or wide-area data processing system networks, including both private networks and public networks such as the Internet.
Data processing systems are often used in conjunction with hierarchical storage management (HSM). Generally, HSM is a data storage technique that monitors the way data is used and functions to move data between two or more “tiers” of storage. “Tiered storage” is a data storage environment made up of two or more kinds of storage that are delineated by differences in at least one of price, performance, capacity and function. For example, hard disk drive arrays and magnetic tape could represent first and second tiers of storage as hard disk drive arrays are associated with higher speed, higher cost and lower capacity while magnetic tape is associated with lower speed, lower cost and higher capacity. As another example, one type of hard disk storage associated with higher speed and lower capacity could be a first tier, another type of hard disk storage associated with lower speed and higher capacity could be a second tier, and a tape library storing tape drives (each of which reads and writes data on a length of magnetic tape) could be as third tier.
In a typical HSM scenario, frequently used data files are stored on a first storage tier (e.g., disk drives) but are eventually transferred or “migrated” to a second or additional storage tiers (e.g., tape) if they are not used after a certain period of time (e.g., a few months). Generally, data migration involves mapping data between storage tiers so as to provide a design for data extraction and data loading between the storage tiers (e.g., to relate data formats between the storage tiers). In any event, data may be automatically moved back to higher tiers (e.g., the first tier) if a user desires to reuse a file on a lower tier.
Long term data storage has traditionally involved use of storage tiers including tape drives due to the favorable unit cost and long archival stability of magnetic tape. Magnetic tape is often stored on removable tape cartridges which allows for the tape to be taken to off-site locations to provide for disaster recovery. A plurality of tape cartridges can be stacked to form a multi-volume cartridge (MVC).
While magnetic tape media presents favorable unit cost and long archival stability, many enterprises and other users desire for more “tape-less” data storage due to long recovery periods, security considerations, the onerous task of implementing non-full restores (e.g., non-sequential restores), and the like. However, many or most mainframe systems still require compatibility with tape drives as part of data storage and archiving. In this regard, VTLs (such as Oracle's Virtual Tape Storage Subsystem (VTSS)) are now being used, each of which is generally in the form of a hard disk storage system that emulates tape libraries or tape drives for use with existing backup software. VTLs generally make use of VTVs which are direct access storage device (DASD) buffers that appear to the operating system as a real tape volume. Data can be written to and read from a VTV and the VTV can be migrated to and recalled from real tape volumes. Multiple VTVs can be stored within a virtual MVC (VMVC).
In the event of a “disaster,” which can include both actual natural disasters and other events, a primary system at a production site may be “down” or otherwise unavailable leading to disruption of operations, lost revenue, and the like. In this regard, many businesses and other enterprises maintain or otherwise implement DR systems or operations which broadly include redundant systems that provide some or all of the functions of the primary systems and typically include full backups of all the data available to the primary systems. In this way, users can, in the event of a disaster, transition to the DR environment until the primary system can be restored, thus reducing lost productivity.
A DR strategy generally has a number of basic components such as migrating or otherwise moving data from a production site to one or more storage tiers or systems of a DR site (e.g., typically at a location that is geographically remote from the production site, such as a different city, different state, and the like), testing one or more DR plans, deploying the DR plan(s) in the event of an actual disaster, and returning to normal operations after a DR test or actual disaster. Testing the recoverability of data and/or software allows the user to validate that its personnel, its information technology (IT) infrastructure, the host software and the storage product itself can handle an unexpected disaster. For instance, the production site of a particular DR setup may include one or more production hosts along with a number of storage tiers and the DR site of the DR setup may be located at a remote distance from the production site and also include one or more storage tiers. Data written to the production storage tiers may also be replicated to one or more storage tiers at the DR site thus providing a secondary copy of the data in the event the production site data or software is lost.
FIG. 1 illustrates a schematic diagram of one type of DR setup 100 made up of a production site 104 and a remote DR site 108 and including the use of one or more VTLs. The production site 104 includes a host 112 (e.g., mainframe) including any appropriate operating system (not shown) that is operable to generate or otherwise manipulate production data. The host 112 includes a host software component (HSC) 116 (e.g., such as Oracle's Virtual Tape Control System (VTCS)) that is broadly operable to create VTVs from the production data and administer migration of the VTVs from host 112 to a first storage tier such as VTL 124 (e.g., such as Oracle's Virtual Tape Storage Subsystem (VTSS)) according to any appropriate enterprise policies (e.g., upon production data being created, according to any appropriate schedule, and the like). Even though the production data is being stored on disk drives on the VTL 124, the HSC 116 interacts with the VTL 124 as if the data is being stored on actual tape drives.
As part of the generation and migration of production data to the VTL 124, one or more production control data sets (CDS s) 120 may also be generated and stored in any appropriate manner. Once a copy of the production data is stored in VTVs in the VTL 124, additional copies of the VTVs are migrated according to any appropriate migration policies (e.g., according to data type, percentage of VTL 124 occupied, any appropriate schedule, and the like) to one or more second storage tiers such as a local tape library 128 and a tape library 132 at the DR site 108 (e.g., via a channel extension). Upon declaration of a disaster at the production site 104 as part of a DR test, the VTV copies stored in the tape library 132 can be recalled to a first tier storage system at the DR site 108 such as VTL 136 at the DR site 108.